The IBM ESA/390 architecture requires some very precise implementation requirements regarding the SET PSW KEY FROM ADDRESS (SPKA) instruction. This instruction modifies the storage key field in the PSW which controls access to pages in main storage for both instruction fetching and operand references. The architecture requires that such key updates be reflected in the protection exception checking for all logically subsequent storage accesses, including the instruction fetch accesses for the immediately following instructions. In a pipelined processor, however, these instruction fetches will In general have been made, and the protection status resolved, prior to the execution of the SPKA instruction. Thus special controls are required to insure that the correct protection checking is performed for each fetch without compromising the performance benefits of pipelined instruction processing.
In previous IBM S/390 processor designs, this problem was solved by either executing the instruction in microcode/millicode or by unconditionally serializing the processor after execution of the SPKA instruction. By serializing the processor, we mean discarding all instructions that have been pre-fetched or decoded but not executed to completion and restarting instruction fetching again.
The IBM ESA/9000 series as disclosed in U.S. Pat. No. 5,345,567 used a method for handling an SPKA instruction with instruction overlap. This method depends on the existence in the processor design of a method of nullifying an instruction at any time during its execution. In a processor which does not incorporate such a method as part of the overall processor design, a different method is required to allow over-lapped execution of SPKA instructions while satisfying all of the requirements of the ESA/390 architecture.
The ESA/390 architecture requires some very precise implementation requirements. Consistent with the disclosure in U.S. Pat. No. 5,345,567, issued Sep. 6, 1994 and entitled "System and method for modifying program status word, system mask, system access key, and address space code with overlap enabled" by Hayen et al, in an S/390 CPU, the SET PSW KEY FROM ADDRESS (SPKA) instruction causes the storage key stored in PSW bits 8:11 to be changed. If the next instruction, after the SPKA, has the Fetch Protect bit equal to 1 in its page's storage key, the S/390 architecture requires a Protection Exception to be generated and the results of that next instruction to be suppressed.
An even more difficult situation to handle is as follows. Suppose an SPKA is at the end of a line and the I-fetch goes out for the next line before the SPKA executes (also assume the next I-fetch misses the caches so it takes a long time to get back). Now if the I-fetch eventually comes back and has the fetch protect bit turned on, it would have been tested against the old PSW key and the Protection Exception would have been missed.
Fortunately, very seldom is the Fetch Protect bit set to 1 for instruction data. But unfortunately, SPKA is a relatively common instruction. Therefore, to obtain the correct S/390 architected results, a CPU's design must account for an infrequent occurrence yet be able accomplish this with few wasted cycles. The problem has been typically been solved by always serializing the processor after the execution of an SPKA instruction. This degrades performance.